SF-3052 Add interactive-widget setting to viewport meta tag #2820
Conversation
|
I'm aware that this is not expected to be supported on Safari. My current stance is that improving the experience for some browsers without harming others is better than what is currently in Live. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2820 +/- ##
==========================================
- Coverage 79.10% 79.10% -0.01%
==========================================
Files 531 531
Lines 30859 30859
Branches 5016 5038 +22
==========================================
- Hits 24411 24410 -1
+ Misses 5674 5662 -12
- Partials 774 787 +13 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Good work Joseph! I think resizes-content makes most sense, even down the road. I briefly read up on this and looks like Chrome/Safari on iOS already does this natively and the changes in Chrome 108 was to bring Android up to par.
Reviewed 1 of 1 files at r1, all commit messages.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on @josephmyers)
|
Interesting, Kyle, as I came to a different conclusion about Safari. It seems like, based on https://github.com/bramus/viewport-resize-behavior/blob/main/explainer.md#the-visual-viewport, that Safari overlays its keyboard, which would result in bottom-fixed content being hidden. It'd be valuable to test this on an actual device, though, though I don't think it should hold up this improvement. Most of what I was seeing on the net indicated that custom visual viewport calculation would be required to resize bottom content for Safari. Maybe these sources are out of date now? |
josephmyers
force-pushed
the
fix/SF-3052
branch
from
8b76ee3
to
9cccd1f
Compare
josephmyers
added
testing complete
Chrome 108 (Nov '22) added support for this new tag, which resizes the visual viewport to the visible space. It does not appear after brief investigation that Safari supports this, and Firefox has been documented to resize with or without this setting. Note that if we choose to hide the bottom bar in the future (which is currently the case), it may not be quite necessary to use "resizes-content" as compared to the other accepted values. It may be that, given that bar will go away, the value "overlays-content" may also suffice. However, the default (resizes-visual for Chrome) likely would cause buggy behavior, given that it currently hides the top bar.
josephmyers
force-pushed
the
fix/SF-3052
branch
from
9cccd1f
to
cee0845
Compare
Chrome 108 (Nov '22) added support for this new tag, which resizes the visual viewport to the visible space. It does not appear after brief investigation that Safari supports this, and Firefox has been documented to resize with or without this setting.
Note that if we choose to hide the bottom bar in the future (which is currently the case), it may not be quite necessary to use "resizes-content" as compared to the other accepted values. It may be that, given that bar will go away, the value "overlays-content" may also suffice. However, the default (resizes-visual for Chrome) likely would cause buggy behavior, given that it currently hides the top bar.
This change is